The body of my HTML:
<body>
<script async src="changeParContent.js"></script>
<script> \\some irrelevant inline code that takes a long time to run
</script>
<p id='par1'>Initial text</p>
</body>
And here is changeParContent.js:
document.getElementById('par1').innerHTML = "The content was changed!"
I expected the Javascript to fail, since I use the async attribute. It means that the script will be downloaded and executed while the HTML is being parsed. Now, since I intentionally slow down the HTML parsing, I expected the javascript to run before the paragraph "p1" was defined.
I thought that I did the one thing you're not supposed to do - defining the DOM elements that are used in the async script below the script.
But it somehow works and the paragraph changes. How can it be?
Async scripts don't really run in any predictable fashion, and it's mainly down to the browser's implementation. For example, you should find the the following works in Chrome:
<body>
<script async src="./changeParContent.js"></script>
<script>
function sleepFor(sleepDuration){
var now = new Date().getTime();
while(new Date().getTime() < now + sleepDuration){ /* Do nothing */ }
}
sleepFor(5000);
</script>
<p id='par1'>Initial text</p>
</body>
However in Firefox the following error is thrown:
Uncaught TypeError: document.getElementById(...) is null
It seems that in both browsers, the slow inline script blocks both the async script from running and the rest of the DOM from loading. Then after this slow script runs, the async script runs in parallel with the rest of the DOM loading. In my experiments, it seems that in Chrome the race is won by the DOM, which causes no errors as the element is loaded by the time the async script runs. However in my Firefox test, the race is won by the async script which throws an error.
I think the lesson here is to trust best practices, even if it looks like there's no issues with your code.